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Abstract 


TRILL (Transparent Interconnection of Lots of Links) supports multi- 
access LAN (Local Area Network) links where a single link can have 
multiple end stations and TRILL switches attached. Where multiple 
TRILL switches are attached to a link, native traffic to and from end 
stations on that link is handled by a subset of those TRILL switches 
called "Appointed Forwarders" as originally specified in RFC 6325, 
with the intent that native traffic in each VLAN be handled by at 
most one TRILL switch. This document clarifies and updates the 
Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and 
obsoletes RFC 6439. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc8139. 
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Les 


Introduction 


The IETF TRILL (Transparent Interconnection of Lots of Links) 
protocol [RFC6325] [RFC7780] provides optimal pairwise data frame 
forwarding without configuration in multi-hop networks with arbitrary 
topology and link technology, safe forwarding even during periods of 
temporary loops, and support for multipathing of both unicast and 
multicast traffic. TRILL accomplishes these by using IS-IS 
(Intermediate System to Intermediate System) [IS-IS] [RFC7176] 
link-state routing and encapsulating traffic using a header that 
includes a hop count. The design supports VLANs, FGLs (Fine-Grained 
Labels) [RFC7172], and optimization of the distribution of 
multi-destination frames based on VLANs and multicast groups. 
Devices that implement TRILL are called TRILL switches or "RBridges" 
(Routing Bridges). 


Section 2 of [RFC7177] discusses the environment for which the TRILL 
protocol is designed and the differences between that environment and 
the typical Layer 3 routing environment. 


TRILL supports multi-access LAN (Local Area Network) links that can 
have multiple end stations and TRILL switches attached. Where 
multiple TRILL switches are attached to a link, native traffic to and 
from end stations on that link is handled by a subset of those 
switches called "Appointed Forwarders" as originally specified in 
[RFC6325], with the intent that native traffic in each VLAN be 
handled by at most one switch. A TRILL switch can be Appointed 
Forwarder for many VLANs. 


The purpose of this document is to update and improve the Appointed 
Forwarder mechanism and free it from the limitations imposed by the 
requirement in its initial design that all appointments fit within a 
TRILL Hello Protocol Data Unit (PDU). This is accomplished by 
requiring support of link-scoped FS-LSPs (Flooding Scope Link State 
PDUs) (Section 8) and providing the option to send appointment 
information in those LSPs. In addition, this document provides a 
number of other optional features to 


1. detect inconsistent VLAN-ID-to-FGL [RFC7172] mappings among the 
TRILL switch ports on a link, as discussed in Section 7, 


2. expedite notification of ports going down so that Appointed 
Forwarders can be adjusted, as discussed in Section 6, and 


3. reduce or eliminate the need for "inhibition" of ports for loop 
safety, as discussed in Section 3.2. 
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This document replaces and obsoletes [RFC6439], incorporating the 
former material in [RFC6439] with these additions. The various 
optimizations are orthogonal and optional. Implementers can choose 
to provide all, some, or none of them, and TRILL switches will still 
be interoperable. In accordance with the TRILL design philosophy, 
these optimizations require zero or minimal configuration, but there 
are a couple of configurable parameters, as summarized in Section 11. 


As described in Appendix C, this document updates [RFC6325] by 
mandating support of E-L1CS FS-LSPs and provides backward 
compatibility in the presence of legacy TRILL switches that do not 
provide this support. It also updates [RFC7177] by providing, as an 
optional optimization, that receipt of the Port-Shutdown message 
specified herein be treated as an event in the state machine 
specified in [RFC7177]. 


This document includes reference implementation details. Alternative 
implementations that interoperate on the wire are permitted. 


The Appointed Forwarder mechanism is irrelevant to any link on which 
end-station service is not offered. This includes links configured 
as point-to-point IS-IS links and any link with all TRILL switch 
ports on that link configured as trunk ports. (In TRILL, 
configuration of a port as a "trunk port" just means that no 
end-station service will be provided. It does not imply that all 
VLANs are enabled on that port.) 


The Appointed Forwarder mechanism has no effect on the formation of 
adjacencies, the election of the Designated RBridge (DRB) [RFC7177] 
for a link, MTU matching, or pseudonode formation. Those topics are 
covered in [RFC7177]. Furthermore, Appointed Forwarder status has 

no effect on the forwarding of TRILL Data frames; it only affects the 
handling of native frames to and from end stations. 


For other aspects of the TRILL base protocol, see [RFC6325], 
[RFC7177], and [RFC7780]. In cases of conflict between this document 
and [RFC6325] or [RFC7177], this document prevails. 


1.1. Appointed Forwarders and Active-Active 


As discussed in [RFC7379], TRILL active-active provides support for 
end stations connected to multiple edge TRILL switches where these 
connections are separate links. Since TRILL Hellos are not forwarded 
between these links, the Appointed Forwarder mechanism as described 
herein operates separately on each such link. 
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1.2. Terminology and Abbreviations 


This document uses the abbreviations and terms defined in [RFC6325], 
some of which are repeated below for convenience, and additional 
abbreviations and terms listed below. 


Data Label mapping: The mapping from VLAN ID to FGL and from FGL to 
VLAN ID. 


DRB: Designated RBridge. The RBridge on a link elected as specified 
in [REC7177] to handle certain decisions and tasks for that link, 
including forwarder appointment as specified herein. 


E-L1CS: Extended Level 1 Circuit Scope (Section 8). 

FGL: Fine-Grained Label [RFC7172]. 

FS-LSP: Flooding Scope Link State PDU (Section 8). 

Link: The means by which adjacent TRILL switches are connected. A 
TRILL link may be various technologies and, in the common case of 
Ethernet, can be a "bridged LAN" -- that is to say, some 
combination of Ethernet links with zero or more bridges, hubs, 
repeaters, or the like. 

LSDB: Link State Database. 

PDU: Protocol Data Unit. 


RBridge: An alternative name for a TRILL switch. 


TRILL: Transparent Interconnection of Lots of Links or Tunneled 
Routing in the Link Layer. 


TRILL switch: A device implementing the TRILL protocol. An 
alternative name for an RBridge. 


Trunk port: A TRILL switch port configured with the "end-station 
service disable" bit on, as described in Section 4.9.1 of 
[RFC6325]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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2. Appointed Forwarders and Their Appointment 


The Appointed Forwarder on a link for VLAN-x is the TRILL switch 
(RBridge) that ingresses native frames from the link and egresses 
native frames to the link in VLAN-x. By default, the DRB (Designated 
RBridge) on a link is in charge of native traffic for all VLANs on 
the link. The DRB may, if it wishes, act as Appointed Forwarder for 
any VLAN, and it may appoint other TRILL switches that have ports on 
the link as Appointed Forwarder for one or more VLANs. 


By definition, the DRB considers the other ports on the link to be 
the ports with which a DRB port has adjacency on that link [RFC7177]. 
If the DRB loses adjacency to a TRILL switch that it has appointed 
as forwarder and the native traffic that was being handled by that 
Appointed Forwarder is still to be ingressed and egressed, it SHOULD 
immediately appoint another forwarder or itself become the forwarder 
for that traffic. 


It is important that there not be two Appointed Forwarders on a link 
that are ingressing and egressing native frames for the same VLAN at 
the same time. Should this occur, it could form a loop where frames 
are not protected by a TRILL Hop Count for part of the loop. (Such a 
condition can even occur through two Appointed Forwarders for two 
different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the 
link are configured to map frames between VLAN-x and VLAN-y as 
discussed in Section 2.5.) While TRILL tries to avoid such 
situations, for loop safety there is also an "inhibition" mechanism 
(see Section 3) that can cause a TRILL switch that is an Appointed 
Forwarder not to ingress or egress native frames. Appointed 
Forwarder status and port "inhibition" have no effect on the 
reception, transmission, or forwarding of TRILL Data or TRILL IS-IS 
frames. Appointed Forwarder status and inhibition only affect the 
handling of native frames. 


As discussed in Section 5, an RBridge may have multiple ports ona 
link. As discussed in [RFC7177], if there are multiple ports with 
the same Media Access Control (MAC) address on the same link, all but 
one will be suspended. The case of multiple ports on a link for the 
same TRILL switch and the case of multiple ports with the same MAC 
address on a link, as well as combinations of these cases, are fully 
accommodated; however, the case of multiple ports on a link for the 
same TRILL switch is expected to be a rare condition, and the case of 
duplicate MAC addresses is not recommended by either TRILL or 

TEEE 802.1 standards. 
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There are six mechanisms by which an RBridge can be appointed or 
unappointed as Appointed Forwarder: 


1. assumption of appointment, when the DRB decides to act as 
Appointed Forwarder for a VLAN, 


2. E-L1CS appointment, as a result of appointments sent by the DRB in 
E-L1CS FS-LSPs, 


3. Hello appointment, as a result of appointments sent by the DRB in 
TRILL Hellos, 


4. as a result of the DRB elections [RFC7177] as discussed in 
Section 2.2, 


5. as a result of a Port-Shutdown message as discussed in Section 6, 
and 


6. as a result of a local configuration action as discussed in 
Section 2.3. 


Mechanisms 2 and 3 are covered in Section 2.1. 
2.1. The Appointment Databases and DRB Actions 


The DRB MAY appoint other RBridges on the link as Appointed 
Forwarders through two mechanisms, "A" and "B", as described below. 


Each RBridge maintains two databases of appointment information: 

(1) its E-L1CS LSDB, which shows appointments that each RBridge on 
the link would make using mechanism A if that RBridge were the DRB, 
and (2) its Hello appointment database, which shows the appointments 
most recently sent by the DRB in a TRILL Hello. The E-L1CS LSDB is 
semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges. 
The Hello appointment database is more transient and is completely 
reset by each Hello received from the DRB that contains any 
appointments; this database is also cleared under other 
circumstances, as described below. An RBridge considers itself to be 
the Appointed Forwarder for VLAN-x if this is indicated by either its 
Hello appointment database or its E-L1CS LSDB entries from the DRB. 
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The two mechanisms by which the DRB can appoint other RBridges on a 
link as Appointed Forwarders are as follows: 


(A) The inclusion of one or more Appointed Forwarders sub-TLVs 
[RFC7176], AppointmentBitmap APPsub-TLVs (Section 10.2), or 
AppointmentList APPsub-TLVs (Section 10.3) in E-L1CS LSPs it 
sends on a link. Appointments sent using this method will not be 
seen by legacy RBridges that do not support E-L1CS (Section 8). 


(B) The inclusion of one or more Appointed Forwarders sub-TLVs 
[REC7176] in a TRILL Hello it sends on the Designated VLAN out of 
the port that won the DRB election. When the DRB sends any 
appointments in a TRILL Hello, it must send all appointments it 
is sending in Hellos for that link in that Hello. Any previous 
appointment it has sent in a Hello that is not included is 
implicitly revoked. 


To avoid the size limitations of the Hello PDU, it is RECOMMENDED 
that the E-L1CS FS-LSP method be used to distribute forwarder 
appointments and that all RBridges on a link use this method to 
advertise the appointments they would make if they were the DRB. 
However, if some RBridges on a link do not support E-L1CS FS-LSPs, 
then Hello appointments must be used for the DRB to appoint such 
legacy RBridges as Appointed Forwarders. 


Although the DRB does not need to announce the VLANs for which it has 
chosen to act as Appointed Forwarder by sending appointments for 
itself, if the DRB wishes to revoke all appointments made in Hellos 
for RBridges other than itself on the link, it can do so by sending a 
TRILL Hello with just an appointment for itself for some VLAN. 


How the DRB decides what other RBridges on the link, if any, to 
appoint as forwarder for some VLAN or VLANs is beyond the scope of 
this document. 


Unnecessary changes in Appointed Forwarders SHOULD NOT be made, as 
they may result in transient lack of end-station service. 


Should the network manager have misconfigured the enabled VLANs and 
Appointed Forwarders, resulting in two RBridges believing they are 
Appointed Forwarders for the same VLAN, the scenario described in 
item 4 in Section 3 will cause one or more of the RBridges to be 
inhibited for that VLAN, thus avoiding persistent loops. 
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When forwarder appointments are being encoded for transmission, 
different patterns of VLANs are most efficiently encoded in different 
ways. The following table gives advice regarding the most efficient 
encoding for a given pattern: 


sub-TLV and Reference 
Pattern of VLAN IDs lenclosing TLV(s) and Reference 


Blocks of consecutive VLANs 
Appointed Forwarders sub-TLV [RFC7176] 
|Router CAPABILITY TLV [RFC7981] 
lor MT-Capability TLV [RFC6329] 


Scattered VLANs within a small range 
AppointmentBitmap APPsub-TLV (Section 10.2) 
| TRILL GENINFO TLV [RFC7357] 


Scattered VLANs over a large range 
AppointmentList APPsub-TLV (Section 10.3) 
| TRILL GENINFO TLV [RFC7357] 


2.2. Appointment Effects of DRB Elections 


When a TRILL switch port on a link wins the DRB election, there are 
four possible cases: 


1. A TRILL switch believes that it was the DRB and remains the DRB: 
there is no change in Appointed Forwarder status. This also 
applies in the corner case where a TRILL switch has more than one 
port on a link, one of which was previously the DRB election 
winner but has just lost the DRB election to a different port of 
the same TRILL switch on the same link (possibly due to management 
configuration of port priorities). In this case, there also is no 
change in which TRILL switch is the DRB. 


2. A TRILL switch believes that it was not the DRB but has now won 
the DRB election and become the DRB on a link: by default, it can 
act as Appointed Forwarder for any VLANs on that link that it 
chooses, as long as its port is not configured as a trunk port and 
has that VLAN enabled (or at least one of its ports meets these 
criteria, if it has more than one port on the link). It ignores 
any previous forwarder appointment information it received from 
other TRILL switches on the link. 
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3. A TRILL switch was not the DRB and does not become the DRB, but it 
observes that the port winning the DRB election has changed: the 
TRILL switch loses all Hello appointments. In addition, there are 
two subcases: 


a. The new winning port and the old winner are ports of different 
TRILL switches on the link. In this case, it switches to using 
the E-L1CS FS-LSP appointments for the winning TRILL switch. 


b. The new winning port and the old winner are ports of the same 
TRILL switch, which has two (or more) ports on the link: 
although the Hello appointments are still discarded, since the 
same TRILL switch is the DRB, the E-L1CS FS-LSP appointments 
are unchanged. 


4. The winning port is unchanged: as in case 1, there is no change in 
Appointed Forwarder status. 


2.2.1. Processing Forwarder Appointments in Hellos 


When a non-DRB RBridge that can offer end-station service on a link 
receives a TRILL Hello that is not discarded for one of the reasons 
given in [RFC7177], it checks the source MAC address and the Port ID 
and System ID in the Hello to determine if it is from the winning DRB 
port. If it is not from that port, any forwarder appointment 
sub-TLVs in the Hello are ignored, and there is no change in the 
receiving RBridge’s Appointed Forwarder status due to that Hello. 
Also, if no forwarder appointment sub-TLVs are present in the TRILL 
Hello, there is no change in the receiver’s Appointed Forwarder 
status due to that Hello. 


However, if the TRILL Hello is from the winning DRB port and the 
Hello includes one or more forwarder appointment sub-TLVs, then the 
receiving RBridge sets its Hello appointment database to be the set 
of VLANs that have both of the following characteristics: 


o The VLAN is listed as an appointment for the receiving RBridge in 
the Hello, and 


o The VLAN is enabled on the port where the Hello was received. 


(If the appointment includes VLAN IDs 0x000 or OxFFF, they are 
ignored, but any other VLAN IDs are still effective.) It then 
becomes Appointed Forwarder for all the VLANs for which it is 
appointed in either its Hello appointment database or its E-L1CS 
FS-LSP appointment database from the DRB if the VLAN is enabled and 
if the port is not configured as a trunk or IS-IS point-to-point 
port. If the receiver was Appointed Forwarder for any VLANs because 
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they were in the Hello appointment database and they are no longer in 
the Hello appointment database, its Appointed Forwarder status for 
such VLANs is revoked. For example, if none of these sub-TLVs in a 
Hello appoints the receiving RBridge, then it loses all Appointed 
Forwarder status on the port where the Hello was received due to 
Hello appointment database entries, but it retains Appointed 
Forwarder status due to E-L1CS FS-LSP appointments. 


The handling of one or more forwarder appointment sub-TLVs in a Hello 
from the winning port that appoints the receiving RBridge is as 
follows: an appointment in an Appointed Forwarders sub-TLV is for a 
specific RBridge and a contiguous interval of VLAN IDs; however, as 
stated above, it actually appoints that RBridge as forwarder only for 
the VLAN or VLANs in that range that are enabled on one or more ports 
that RBridge has on the link (ignoring any ports configured as 

trunk ports or as IS-IS point-to-point ports). 


There is no reason for an RBridge to remember that it received a 
valid appointment Hello message for a VLAN that was ineffective 
because the VLAN was not enabled on the port where the Hello was 
received or because the port was a trunk or point-to-point port. It 
does not become Appointed Forwarder for such a VLAN just because that 
VLAN is later enabled or the port is later reconfigured. 


The limitations due to the size of the Hello PDU make it desirable to 
use E-L1CS FS-LSPs for appointment. But if Hellos need to be used, 
due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the 
remainder of this section provides a method to maximize the use of 
the limited space in Hellos for forwarder appointment. 


It should be straightforward for the DRB to send, within one Hello, 
the appointments for several dozen VLAN IDs or several dozen blocks 
of contiguous VLAN IDs. Should the VLANs that the DRB wishes to 
appoint be inconveniently distributed (for example, the proverbial 
case where a DRB (say RB1) wishes to appoint RB2 as forwarder for all 
even-numbered VLANs and appoint RB3 as forwarder for all odd-numbered 
VLANs), the following method may be used: 


The network manager normally controls what VLANs are enabled on an 
RBridge port. Thus, the network manager can appoint an RBridge as 
forwarder for an arbitrary set of scattered VLANs by enabling only 
those VLANs on the relevant port (or ports) and then having the 
DRB send an appointment that appears to appoint the target RBridge 
as forwarder for all VLANs. However, for proper operation and 
inter-RBridge communication, the Designated VLAN for a link SHOULD 
be enabled on all RBridge ports on that link, and it may not be 
desired to appoint the RBridge as forwarder for the 

Designated VLAN. Thus, in the general case, two appointments 
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would be required, although only one appointment would be required 
if the Designated VLAN value were extremely low or high (such as 
VLAN OxFFE) or the default value (VLAN 1). 


For example, assume that the DRB wants RB2 to be Appointed Forwarder 
for all even-numbered VLANs and the Designated VLAN for the link is 
VLAN 101. The network manager could cause all even-numbered VLANs 
plus VLAN 101 to be enabled on the relevant port of RB2 and then, 
with the desired effect, cause the DRB to send appointments to RB2 
appointing it forwarder for all VLANs from 1 through 100 and from 102 
through 4,094. 


2.2.2. Frequency of Hello Appointments 


Appointments made through E-L1CS FS-LSPs use the same IS-IS timing 
constants as those for LSP flooding. The general IS-IS link-state 
flooding mechanism is robust and includes acknowledgments so that it 
automatically recovers from lost PDUs, rebooted TRILL switches, and 
the like. 


For Hello appointments, it is not necessary for the DRB to include 
the Hello forwarder appointments in every TRILL Hello that it sends 
on the Designated VLAN for a link. For loop safety, every RBridge is 
required to indicate, in every TRILL Hello it sends in VLAN-x on a 
link, whether it is an Appointed Forwarder for VLAN-x for that link 
(see item 4 in Section 3, but see also Section 4). It is also 
RECOMMENDED that the DRB have enabled all VLANs for which end-station 
service will be offered on the link as well as the Designated VLAN. 
Thus, the DRB will generally be informed by other RBridges on the 
link of the VLANs for which they believe that they are the Appointed 
Forwarder. If this matches the appointments the DRB wishes to make, 
it is not required to resend its forwarder appointments; however, for 
robustness, especially in cases such as VLAN misconfigurations ina 
bridged LAN link, it is RECOMMENDED that the DRB send its forwarder 
appointments on the Designated VLAN at least once per its Holding 
Time on the port that won the DRB election. 


2.2.3. Appointed Forwarders Hello Limit 


The Hello mechanism of DRB forwarder appointment and the limited 
length of TRILL Hellos impose a limit on the number of RBridges on a 
link that can be Appointed Forwarders when E-L1CS FS-LSP appointments 
cannot be used due to the presence of legacy RBridges. To obtain a 
conservative estimate of this limit, assume that no more than 

1,000 bytes are available in a TRILL Hello for such appointments. 
Assume also that it is desired to appoint various RBridges on a link 
as forwarder for arbitrary non-intersecting sets of VLANs. Using the 
technique discussed at the end of Section 2.2.1 would generally 
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require two appointments, or 12 bytes, per RBridge. With allowance 
for sub-TLV and TLV overhead, appointments for 83 RBridges would 

fit in under 1,000 bytes. Including the DRB, this implies a link 
with 84 or more RBridges attached. Links with more than a handful of 
RBridges attached are expected to be rare, and in any Case such 
limitations are easily avoided by using E-L1CS FS-LSP appointment. 


2.3. Effects of Local Configuration Actions on Appointments 


Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder 
status that RBridge has for VLAN-x, unless VLAN-x is enabled on some 
other port that the RBridge has connected to the same link. 
Configuring a port as a trunk port or point-to-point port revokes 
any Appointed Forwarder status that depends on enabled VLANs at 

that port. 


Causing a port to no longer be configured as a trunk or 
point-to-point port or enabling VLAN-x on a port does not necessarily 
Cause the RBridge to become an Appointed Forwarder for the link that 
port is on. However, such actions allow the port's RBridge to become 
Appointed Forwarder by choice if it is the DRB or, if it is not the 
DRB on the link, by appointment as indicated by the Hello appointment 
database or the E-L1CS FS-LSP appointment database. 


2.4. Overload and Appointed Forwarders 


A TRILL switch in link-state overload [RFC7780] will, in general, do 
a poorer job of forwarding frames than a TRILL switch not in 
overload, because the TRILL switch not in overload has full knowledge 
of the campus topology. For example, as explained in [RFC7780], an 
overloaded TRILL switch may not be able to distribute 
multi-destination TRILL Data packets at all. 


Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an 
Appointed Forwarder, and if an Appointed Forwarder becomes 
overloaded, the DRB SHOULD reassign VLANs from the overloaded RBridge 
to another RBridge on the link that is not overloaded, if one is 
available. 


A counter-example where it would be best to appoint an RBridge in 
overload as Appointed Forwarder would be if RB1 was in overload but 
all end stations in the campus in VLAN-x were on links attached to 


RB1. In such a case, RB1 would never have to route VLAN-x 
end-station traffic as TRILL Data packets but would always be 
forwarding them locally as native frames. In this case, RB1 


SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed 
Forwarder on any such links, even if RB1 is in overload. 
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There is also the case where it is unavoidable to appoint an RBridge 
in overload as Appointed Forwarder, because all RBridges on the link 
are in overload. 


These cases do not violate the prohibition in the IS-IS standard 
against routing through an overloaded node. Designation as an 
Appointed Forwarder has to do with the ingress and egress of native 
frames and has nothing to do with the IS-IS routing of TRILL Data 
packets through a TRILL switch. 


Overload does not affect DRB election, but a TRILL switch in overload 
MAY reduce its own priority to be the DRB. 


2.5. VLAN Mapping within a Link 


TRILL Hellos include a field that is set to the VLAN in which they 
are sent when they are sent on a link technology such as Ethernet 
that has outer VLAN labeling. (For link technologies such as PPP 
that do not have outer VLAN labeling, this Hello field is ignored.) 
If a TRILL Hello arrives on a different VLAN than the VLAN on which 
it was sent, then VLAN mapping is occurring within the link. VLAN 
mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed 
Forwarders for the VLANs are different. If such mapping within a 
link was allowed and occurred on two or more links so that there was 
a cycle of VLAN mappings, a multi-destination frame would loop 
forever. Such a frame would be "immortal". For a specific example, 
see Appendix B. 


To prevent this potential problem, if the DRB on a link detects VLAN 
mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it 
MUST make or revoke appointments so as to assure that the same TRILL 
switch (possibly the DRB) is the Appointed Forwarder on the link for 
both VLAN-x and VLAN-y. 

3. The Inhibition Mechanism 
A TRILL switch has, for every link on which it can offer end-station 
service (that is, every link for which it can act as an Appointed 
Forwarder), the following timers, denominated in seconds: 
—- a DRB inhibition timer, 
- a root bridge change inhibition timer, and 


- up to 4,094 VLAN inhibition timers, one for each legal VLAN ID. 


The DRB and root bridge change inhibition timers MUST be implemented. 
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The loss of native traffic due to inhibition will be minimized by 
logically implementing a VLAN inhibition timer per each VLAN for 
which end-station service will ever be offered by the RBridge on the 
link; this SHOULD be done. (See Appendix A for an example 
illustrating a potential problem that is solved by VLAN inhibition 
timers.) However, if implementation limitations make a full set of 
such timers impractical, the VLAN inhibition timers for more than one 
VLAN can, with care, be merged into one timer. In particular, an 
RBridge MUST NOT merge the VLAN inhibition timers for two VLANs if it 
is the Appointed Forwarder for one but not for the other, as this can 
lead to unnecessary indefinitely prolonged inhibition. In a given 
implementation limitation, there will be safe operations, albeit with 
more loss of native frames than would otherwise be required, even if 
only two VLAN inhibition timers are provided: one for the VLANs for 
which the RBridge is the Appointed Forwarder and one for all other 
VLANs. Thus, at least two VLAN inhibition timers MUST be 
implemented. Where a VLAN inhibition timer represents more than one 
VLAN, an update or test that would have been done to the timer for 
any of the VLANs is performed on the merged timer. 


These timers are set as follows: 


1. On booting or management reset, each port will have its own set of 
timers, even if two or more such ports are on the same link, 
because the TRILL switch will not have had a chance yet to learn 
that they are on the same link. All inhibition timers are set to 
"expired", except the DRB inhibition timer that is set in 
accordance with item 2 below. The DRB inhibition timer is handled 
differently, because each port will initially believe that it is 
the DRB. 


2. When a TRILL switch decides that it has become the DRB on a link, 
including when it is first booted or reset by management, it sets 
the DRB inhibition timer to the Holding Time of its port on that 
link that won the DRB election. 


3. When a TRILL switch decides that it has lost DRB status on a link, 
it sets the DRB inhibition timer to "expired". 


Note: In the corner case where one port of a TRILL switch was the DRB 
election winner but later lost the DRB election to a different port 
of the same TRILL switch on that link (perhaps due to management 
configuration of port priorities), neither item 2 nor item 3 above 
applies, and the DRB timer is not changed. 


4. When a TRILL switch RB1 receives a TRILL Hello asserting that the 
sender is the Appointed Forwarder and that Hello either 
(1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated 
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inside the Hello, RB1 uses as its VLAN-x inhibition timer for the 
link (1) that timer's existing value or (2) the Holding Time in 
the received Hello, whichever is longer. A TRILL switch MUST 
maintain VLAN inhibition timers covering a link to which it 
connects if it can offer end-station service on that link, even if 
it is not currently the Appointed Forwarder for any VLAN on that 
link. 


5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a 
link and VLAN-x was previously not enabled on any of RB1's ports 
on that link, it sets its VLAN inhibition timer for VLAN-x for 
that link to its Holding Time for that port. This is done even if 
the port is configured as a trunk or point-to-point port, as long 
as there is some chance it might later be configured not to be a 


trunk or point-to-point port. Remember, inhibition has no effect 
on TRILL Data or IS-IS packets; inhibition only affects native 
frames. 


6. When a TRILL switch detects a change in the common spanning tree 
root bridge on a port, it sets its root bridge change inhibition 
timer for the link to an amount of time that defaults to 
30 seconds and is configurable to any value from 30 down to 
0 seconds. This condition will not occur unless the TRILL switch 
is receiving Bridge PDUs (BPDUs) on the port from an attached 
bridged LAN; if no BPDUs are being received, the root bridge 
change inhibition timer will never be set. It is safe to 
configure this inhibition time to the settling time of an attached 
bridged LAN. For example, if it is known that the Rapid Spanning 
Tree Protocol (RSTP) [802.10] is running throughout the attached 
bridged LAN, it is safe to configure this inhibition time to 
7 seconds or, if the attached bridges have been configured to have 
a minimum Bridge Hello Timer, it is safe to configure it to 
4 seconds. Further optimizations are specified in Section 3.2. 


7. When a TRILL switch decides that one of its ports (or a set of its 
ports) P1 is on the same link as another one of its ports (or set 
of its ports) P2, the inhibition timers are merged into a single 
set of inhibition timers by using the longest value of the 
corresponding timers as the initial value of the merged timers. 


8. When an RBridge decides that a set of its ports that it had been 
treating as being on the same link are no longer on the same link, 
those ports will necessarily be on two or more links (up to one 
link per port). This is handled by cloning a copy of the timers 
for each of the two or more links to which the TRILL switch has 
decided these ports connect. 
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3.1. Inhibited Appointed Forwarder Behavior 


Inhibition has no effect on the receipt or forwarding of TRILL Data 
packets or TRILL IS-IS packets. It only affects ingressing and 
egressing native frames. 


An Appointed Forwarder for a link is inhibited for VLAN-x if: 
1. its DRB inhibition timer for that link is not expired, 


2. its root bridge change inhibition timer for that link is not 
expired, or 


3. its VLAN inhibition timer for that link covering VLAN-x is not 
expired. 


If a VLAN-x Appointed Forwarder for a link is inhibited and receives 
a TRILL Data packet whose encapsulated frame would normally be 
egressed to that link in VLAN-x, it decapsulates the native frame as 
usual. However, it does not output it to, or queue it for, that 
link, although, if appropriate (for example, the frame is 
multi-destination), it may output it to, or queue it for, other 
links. 


If a VLAN-x Appointed Forwarder for a link is inhibited and receives 
a native frame in VLAN-x that would normally be ingressed from that 
link, the native frame is ignored, except for address learning. 


A TRILL switch with one or more unexpired inhibition timers, possibly 
including an unexpired inhibition timer covering VLAN-x, is still 
required to indicate in TRILL Hellos it sends on VLAN-x whether or 
not it is Appointed Forwarder for VLAN-x for the port on which it 
sends the Hello. 


3.2. Root Bridge Change Inhibition Optimizations 


The subsections below specify three optimizations that can reduce the 
inhibition time of an RBridge port under certain circumstances for 
changes in the root Bridge ID [802.10] being received by that port 
and thus decrease any transient interruption in end-station service 
due to inhibition. TRILL switches MAY implement these optimizations. 
In the first two optimizations, inhibition can be eliminated entirely 
under some circumstances. These optimizations are a bit heuristic in 
that with some unlikely multiple changes in a bridged LAN that occur 
simultaneously, or nearly so, the optimizations make transient 
looping more likely. 
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3.2.1. Optimization for Change to Lower Priority 


Assume that the root Bridge ID being received on an RBridge port 
changes to a new root Bridge ID with lower priority and a different 
root Bridge MAC address due to a single change in the bridged LAN. 
There are two possible reasons for this: 


1. The bridged LAN to which the port is connected has partitioned 
into two or more parts due to link failure or otherwise, and the 
port is connected to a part that does not contain the original 
root bridge. 


2. The original root bridge has been reconfigured to have a lower 
priority, and a new root has taken over. 


Both of these scenarios are safe conditions that do not require 
inhibition. 


3.2.2. Optimization for Change to Priority Only 


Assume that the root Bridge ID changes due to a single change in the 
bridged LAN but only the explicit priority portion of it changes. 
This means that the 48-bit MAC address portion of the root Bridge ID 
is unchanged and the root bridge has been reconfigured to have a 
different priority. Thus, the same bridge is root, and a topology 
change is not indicated. Thus, it is safe to ignore this sort of 
root Bridge ID change and not invoke the inhibition mechanism. 


3.2.3. Optimizing the Detection of Completed Settling 


A dangerous Case is the merger of bridged LANs that had been separate 
TRILL links in the same campus. In general, these links may have had 
different Appointed Forwarders on them for the same VLAN. Without 

inhibition, loops involving those VLANs could occur after the merger. 


Only native frames egressed and ingressed by RBridges are a potential 
problem. TRILL Data packets are either 


1. individually addressed (TRILL Header M bit = 0) and will be 
ignored if delivered to any incorrect TRILL switch ports or 


2. multicast (TRILL Header M bit = 1), in which case the Reverse Path 
Forwarding Check discards any copies delivered to incorrect TRILL 


switch ports. 


Thus, there is no need for inhibition to affect the sending or 
receiving of TRILL Data packets, and inhibition does not do so. 
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However, root bridge change inhibition is only needed until TRILL 
Hellos have been exchanged on the merged bridged LAN. Hellos 
indicate Appointed Forwarder status and, in general, after an 
exchange of Hellos the new merged bridged LAN link will, if 
necessary, be rendered TRILL loop safe by VLAN inhibition so that 
root bridge change inhibition is no longer needed. 


TRILL switches are required to advertise in their link state the IDs 
of the root Bridge IDs they can see. If an RBridge port sees a 
change in root Bridge ID from Rootl to Root2, it is safe to terminate 
root bridge change inhibition on that port as soon as Hellos have 
been received on the port from all RBridges that can see Rootl or 
Root2, except any such RBridge that is no longer reachable. 


In further detail, when a change from Rootl to Root2 is noticed at a 
port of RB1, RB1 associates with that port a list of all of the 
reachable RBridges, other than itself, that had reported in their 


LSPs that they could see either Rootl or Root2. It then removes from 
this list any RBridge that becomes unreachable from RB1 or from which 
it has received a Hello on that port. If there is a subsequent 


change in root Bridge ID being received before this list is empty, 
say to Root7, then those RBridges reporting in their LSPs that they 
Can see Root7 are added to the list. Root bridge change inhibition 
can be terminated for the port as soon as either the timeout is 
reached or this list of RBridges is empty. 


If the optimizations described in Sections 3.2.1 and/or 3.2.2 are in 
effect at an RBridge port and indicate that no inhibition is needed, 
then the mechanism described in this section is not needed either. 


4. Optional TRILL Hello Reduction 


If a network manager has sufficient confidence that they know the 
configuration of bridges, ports, and the like, within an Ethernet 
link, they may be able to reduce the number of TRILL Hellos sent on 
that link by sending Hellos in fewer VLANs -- for example, if all 
TRILL switches on the link will see all Hellos without VLAN 
constraints. However, because adjacencies are established in the 
Designated VLAN, an RBridge MUST always attempt to send Hellos in the 
Designated VLAN. 


Hello reduction makes TRILL less robust in the face of decreased VLAN 
connectivity within a link, such as partitioned VLANs, VLANs disabled 
on ports, or disagreement over the Designated VLAN; however, as long 
as all RBridge ports on the link are configured for the same 

Desired Designated VLAN [RFC6325], can see each other’s frames in 
that VLAN, and utilize the mechanisms specified below to update VLAN 
inhibition timers, operations will be safe. (These considerations 
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do not arise on links between RBridges that are configured as 

point to point, since, in that case, each RBridge sends 
point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames 
only in what it believes to be the Designated VLAN of the link 
(although it may send them untagged) and no native frame end-station 
service is provided. Thus, for such links, there is no reason to 
send Hellos in any VLAN other than the Designated VLAN.) 


The provision for a configurable set of "Announcing VLANs", as 
described in Section 4.4.3 of [RFC6325], provides a mechanism in the 
TRILL base protocol for a reduction in TRILL Hellos. 


To maintain loop safety in the face of occasional lost frames, 
RBridge failures, link failures, new RBridges coming up on a link, 
and the like, the inhibition mechanism specified in Section 3 is 
still required. Strictly following Section 3, a VLAN inhibition 
timer can only be set by the receipt of a Hello sent or received in 
that VLAN. Thus, to safely send a reduced number of TRILL Hellos on 
a reduced number of VLANs requires additional mechanisms to set the 
VLAN inhibition timers at an RBridge. Two such mechanisms, specified 
below, expand upon the mechanisms provided in Section 3. Support for 
both of these mechanisms is indicated by a capability bit in the 
PORT-TRILL-VER sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe 
for an RBridge to send TRILL Hellos on fewer VLANs than the set of 
VLANs recommended in [RFC6325] on a link unless all its adjacencies 
on that link (excluding those in the Down state [RFC7177]) indicate 
support of these mechanisms and these mechanisms are in use. 


1. An RBridge RB2 MAY include in any TRILL Hello an Appointed 
Forwarders sub-TLV [RFC7176] appointing itself for one or more 
ranges of VLANs. The Appointee Nickname field(s) in the 
self-appointment Appointed Forwarders sub-TLV MUST be the same as 
the Sender Nickname in the Special VLANs and Flags sub-TLV in the 
TRILL Hellos sent by RB2. This indicates that the sending RBridge 
believes that it is Appointed Forwarder for those VLANs. For each 
of an RBridge’s VLAN inhibition timers for every VLAN in the block 
or blocks listed in the Appointed Forwarders sub-TLV, the RBridge 
sets that timer to either (1) its current value or (2) the Holding 
Time of the Hello containing the sub-TLV, whichever is longer. 
This is backward compatible. That is, such sub-TLVs will have no 
effect on any legacy receiving RBridge not implementing this 
mechanism unless RB2, the sending RBridge, is the DRB sending 
Hellos on the Designated VLAN. If RB2 is the DRB, it MUST include 
in the Hello all forwarder appointments, if any, for RBridges 
other than itself on the link. 
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2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When 
RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2 
on any VLAN, RB1 updates the VLAN inhibition timers for all the 
VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is 
Appointed Forwarder. Each such timer is updated to (1) its 
current value or (2) the Holding Time of the TRILL Hello 
containing the VLANs Appointed sub-TLV, whichever is longer. This 
sub-TLV will be an unknown sub-TLV to RBridges not implementing 
it, and such RBridges will ignore it. Even if a TRILL Hello sent 
by the DRB on the Designated VLAN includes one or more VLANs 
Appointed sub-TLVs, as long as no Appointed Forwarders sub-TLVs 
appear, the Hello is not required to indicate all forwarder 
appointments. 


Two different encodings are provided above to optimize the listing of 
VLANs. Large blocks of contiguous VLANs are more efficiently encoded 
with the Appointed Forwarders sub-TLV, and scattered VLANs are more 
efficiently encoded with the VLANs Appointed sub-TLV. These 
encodings may be mixed in the same Hello. The use of these sub-TLVs 
does not affect the requirement that the AF bit in the Special VLANs 
and Flags sub-TLV MUST be set if the originating RBridge believes 
that it is Appointed Forwarder for the VLAN in which the Hello 

is sent. 


If the above mechanisms are used on a link, then each RBridge on the 
link MUST send Hellos in one or more VLANs with such VLANs Appointed 
sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s), 
and the AF bit is appropriately set such that no VLAN inhibition 
timer will improperly expire unless three or more Hellos are lost. 
For example, an RBridge could announce all VLANs for which it 
believes that it is Appointed Forwarder in a Hello sent on the 
Designated VLAN three times per Holding Time. 


5. Multiple Ports on the Same Link 


A TRILL switch may have multiple ports on the same link. Some of 
these ports may be suspended due to MAC address duplication, as 
described in [RFC7177]. Suspended ports never ingress or egress 
native frames. 


If a TRILL switch has one or more non-suspended ports on a link and 
those ports offer end-station service -- that is, those ports are not 
configured as point-to-point or trunk ports -- then that TRILL switch 
is eligible to be an Appointed Forwarder for that link. It can 
become Appointed Forwarder in the ways discussed in Section 2. 
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If a TRILL switch that is the Appointed Forwarder for VLAN-x on a 
link has multiple non-suspended ports on that link, it may load-share 
the task of ingressing and egressing VLAN-x native frames across 
those ports however it chooses, as long as there is no case in which 
a frame it egresses onto the link from one port can be ingressed on 
another one of its ports, creating a loop. If the TRILL switch is 
the Appointed Forwarder for multiple VLANs, a straightforward thing 
to do would be to partition those VLANs among the ports it has on 

the link. 


6. Port-Shutdown Messages 


A TRILL switch may note that one of its ports has failed, or it 

may be about to shut down that port. If the port is on a link along 
with ports of other TRILL switches, those TRILL switches will not 
notice the port shutdown or failure using TRILL base protocol 
mechanisms until there is a failure to receive a number of Hellos 
from that port. This can take many seconds. Network topology 
(adjacencies) and forwarder appointments can react more rapidly to 
port shutdown or failure through explicit notification. As discussed 
below, this notification SHOULD be provided through the Port-Shutdown 
message. 


6.1. Planned Shutdown and Hellos 


A TRILL switch that is shutting down one of its ports (say P1) soon 
SHOULD reduce its Holding Time on that port, so that the shutdown 
will be more rapidly noticed by adjacent RBridges that might not 
support the Port-Shutdown message. 


6.2. Port-Shutdown Message Structure 


The Port-Shutdown message is an RBridge Channel message [RFC7178] 
using RBridge Channel Protocol number 0x006. The payload specific to 
the Channel Protocol consists of a list of Port IDs (see 

Section 4.4.2 of [RFC6325]) for the port or ports that have failed or 
are being shut down, as shown in the diagram below. Support for the 
Port-Shutdown message is advertised by simply advertising support for 
its RBridge Channel Protocol in the RBridge Channel Protocols sub-TLV 
[RFC7176]. 
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0 1 2 3 
012345678901234567890123456789021 


TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| v |aAlc|M| REsv |F| Hop Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| 


| Egress Nickname Ingress Nickname 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Special Inner.MacDA = All-Egress-RBridges 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Special Inner.MacDA (cont.) | Inner.MacSA 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Inner.MacSA (cont.) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

RBridge Channel Header: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=0x006| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Flags | ERR=0 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Information specific to the Port-Shutdown Channel Protocol: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Port ID 1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Port ID 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

PE IEE eae E 

| Port ID K 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| 
+ 
| 
+ 


6.3. Port-Shutdown Message Transmission 


For robustness, a TRILL switch sends a configurable number of copies 
of Port-Shutdown messages separated by a configurable time interval. 
The default number of copies is two, although this can be configured 
as one copy or as three copies, and the default interval is 

20 milliseconds (see Section 6.6). As with any "adjacency critical" 
message, the Port-Shutdown message SHOULD be sent with the highest 
priority, which is priority 7, and SHOULD NOT be marked as 

"drop eligible". 


If a failure of port P1 on RBridge RB2 is detected by RB2, then the 
Port-Shutdown message announcing this failure is sequentially unicast 
through the rest of the TRILL campus to all RBridges (1) with which 
P1 had an adjacency and (2) that are advertising support for the 
Port-Shutdown RBridge Channel Protocol. 
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If a port shutdown is planned within 1 second, then the TRILL switch 
ceases to send Hellos out of the port being shut down and either 

(1) sends the Port-Shutdown message to RBridge ports on the link 
advertising support of the Port-Shutdown RBridge Channel Protocol or 
(2) broadcasts the Port-Shutdown message announcing this event 
through the port as follows: 


- The Outer.MacDA is the All-RBridges multicast address. 

- If an outer VLAN tag is present, it specifies the Designated VLAN 
for the link, SHOULD specify priority 7, and SHOULD NOT specify 
"drop eligible". 


- In the TRILL Header, the egress nickname is All-RBridges, and the 
M bit in the TRILL Header is set to 0. 


- In the RBridge Channel Header, the MH and NA bits are zero. 
There is no need for a special message to indicate that a port Pl has 
come back up or that a shutdown has been "canceled". This is 


indicated by simply sending Hellos out of port Pl. 


6.4. Port-Shutdown Message Reception 


When a TRILL switch RB1 receives a Port-Shutdown message, RB1 checks 
to see if the ingress nickname specifies some TRILL switch RB2 with 


which RB1 has one or more adjacencies. If so, it drops those 
adjacencies that are to RB2 ports whose Port IDs are listed in the 
Port-Shutdown message. There could be more than one if RB2 had 


multiple ports on the link that are going down. 


If RB1 is the DRB and this eliminates all adjacencies on a link 
between the DRB and RB2, then, for all VLANs whose ingress/egress was 
being handled by RB2, the DRB either starts acting as Appointed 
Forwarder or appoints some new TRILL switch with which it has 
adjacency as Appointed Forwarder. 


6.5. Port-Shutdown Message Security 


Port-Shutdown messages can be secured through the use of the RBridge 
Channel Header Extension security feature [RFC7978]. 
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6. 


7. 


6. Port-Shutdown Configuration 


There are two Port-Shutdown configuration parameters, as listed 
below. Section 6.3 provides details regarding their use. 


Parameter Default Range 
PShutdownRepeat 2 13: 
PShutdownDelay 20 milliseconds 0-1,000 milliseconds 


FGL-VLAN Mapping Consistency Checking 


TRILL switches support 24-bit Fine-Grained Labels as specified in 
[RFC7172]. Basically, a VLAN ID in native traffic between an edge 
TRILL switch and an end station is mapped from/to an FGL as an 
Inner.Label in TRILL Data packets. Since the Appointed Forwarder for 
a VLAN will be ingressing and egressing such native traffic, the 
mapping configured at the Appointed Forwarder is the mapping 
performed. 


However, the Appointed Forwarder for VLAN-x on a link can change for 
reasons discussed elsewhere in this document. Thus, all 

TRILL switches on a link that are configured with an FGL-VLAN mapping 
SHOULD be configured with the same mapping. Otherwise, traffic might 
unpredictably jump from one FGL to another when the Appointed 
Forwarder changes. TRILL switches SHOULD advertise their mapping on 
the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs 
(Sections 10.4 and 10.5) so that consistency checking can be 
automated. 


A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees 
advertised by other TRILL switches on a link with its own and alert 
the network operator if they are inconsistent. "Inconsistent" means 
that (1) one TRILL switch maps FGL-z to VLAN-x while another maps 
FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while 
another maps VLAN-x to FGL-z, all on the same link. 


Depending on how the network is being managed, a transient 
inconsistency may not be a problem. Thus, the network operator 
SHOULD NOT be alerted unless the inconsistency persists for a period 
of time that defaults to the TRILL switch’s Holding Time and is 
configurable to between 0 seconds and 2**16 - 1 seconds, 

where 2**16 - 1 is a special value and indicates that such alerts 
are disabled. 
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8. Support of E-L1CS 


All TRILL switches MUST support the E-L1CS flooding scope [RFC7356], 
Extended Level 1 Flooding Scope (E-L1FS) [RFC7780], and base LSPs 
[IS-IS]. It will be apparent to any TRILL switch on a link if any 
other TRILL switch on the link is a legacy implementation not 
supporting E-L1CS because, as stated in [RFC7780], all TRILL switches 
MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL 
Hellos they send. This support of E-L1CS increases the amount of 
information from each TRILL switch that can be synchronized on the 
link, compared with the information capacity of Hellos, by several 
orders of magnitude. 


For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs 
(Flooding Scope Complete Sequence Number PDUs) [RFC7356], and E-L1CS 
FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [RFC7356]) 
MUST NOT exceed 1,470 bytes in length; however, any such E-L1CS PDU 
that is received that is longer than 1,470 bytes is processed 
normally. 


As with any type of IS-IS LSP, FS-LSPs are identified by the 

System ID of the originating router (TRILL switch) and the 

fragment number. In particular, there is no port identifier in the 
header of an E-L1CS PDU. Thus, a TRILL switch RB1 with more than one 
non-suspended port on a link (Section 5) transmitting such a PDU MAY 
transmit it out of any one or more of such ports. RB1 will generally 
receive such a PDU that other TRILL switches send on all of RB1's 
ports on the link. In addition, with multiple ports on the link, it 
will receive any such PDU that it sends on the ports it has on the 
link other than the transmitting port. 


8.1. Backward Compatibility 
Future TRILL specifications making use of E-L1CS MUST specify how 
situations involving a TRILL link will be handled when one or more 


TRILL switches attached to that link support E-L1CS and one or more 
do not. 
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9. Security Considerations 


This document provides improved documentation of the TRILL Appointed 
Forwarder mechanism. It does not change the security considerations 
of the TRILL base protocol as described in Section 6 of [RFC6325]. 


The Port-Shutdown messages specified in Section 6 are sent using the 
RBridge Channel facility [RFC7178]. Such messages SHOULD be secured 
through the use of the RBridge Channel Header Extension [RFC7978]. 
If they are not adequately secured, they are a potential 
denial-of-service vector. 


The E-L1CS FS-LSPs added by Section 8 are a type of IS-IS PDU 
[RFC7356]. As such, they are securable through the addition of 
Authentication TLVs [RFC5310] in the same way as Hellos or other 
IS-IS PDUs. 


10. Code Points and Data Structures 


This section provides IANA considerations for this document and 
specifies the structures of the AppointmentBitmap, Appointmentlist, 
VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs. 
These APPsub-TLVs appear within a TRILL GENINFO TLV [RFC7357] in 
E-L1CS FS-LSPs [RFC7356]. 


10.1. IANA Considerations 
TANA has assigned four new APPsub-TLV type codes from the range below 


255 and entered them in the "TRILL APPsub-TLV Types under IS-IS TLV 
251 Application Identifier 1" registry as follows: 


Type Name Reference 
17 AppointmentBitmap [RFC8139] 
18 AppointmentList [RFC8139] 
19 FGL-VLAN-Bitmap [RFC8139] 
20 FGL-VLAN-Pairs [RFC8139] 


IANA has assigned a new RBridge Channel Protocol number in the range 
assigned by Standards Action [RFC5226] and updated the "RBridge 
Channel Protocols" registry as follows: 


Protocol Description Reference 


0x006 Port-Shutdown [RFC8139] 


Eastlake, et al. Standards Track [Page 28] 


RFC 8139 TRILL: Appointed Forwarders June 2017 


IANA has updated the reference for the "Hello reduction support" bit 
in the "PORT-TRILL-VER Sub-TLV Capability Flags" registry to refer to 
this document. 


10.2. AppointmentBitmap APPsub-TLV 


The AppointmentBitmap APPsub-TLV provides an efficient method for a 
TRILL switch to indicate which TRILL switches it appoints as 
forwarders for which VLAN IDs when those VLAN IDs are relatively 
compact (that is, they do not span a large numeric range). Such an 
appointment is only effective when the appointing TRILL switch is 
the DRB. 
Taaa T 

0123456789012345 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | (2 bytes) 
dh + hh q o + + o + + +++ 

| Length | (2 bytes) 
dh + hh + e Po + + o + + +++ 

| Appointee Nickname | (2 bytes) 
E 

| RESV | Starting VLAN ID | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Bit Map ... (variable) 


+—+-+-+-+-+-+-+-... 
o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV 17. 


o Length: 4 + size of bit map in bytes. If Length is less than 4, 
the APPsub-TLV is corrupt and MUST be ignored. 


o Appointee Nickname: The nickname of the TRILL switch being 
appointed as forwarder. 


o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 


o Starting VLAN ID: The smallest VLAN ID to which the bits in the 
Bit Map correspond. 


o Bit Map: A bit map of the VLANs for which the TRILL switch with 
Appointee Nickname is appointed as the forwarder. The size of the 
bit map is length minus 4. If the size of the bit map is zero, 
no appointments are made. 
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Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the 
VLAN whose ID appears in the Starting VLAN ID field. Bit 1 is for 
that VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and 

so on, with Bit N generally being Starting VLAN ID plus N. 

VLAN 0x000 and VLAN OxFFF, or any larger ID, are invalid and are 
ignored. 


If the AppointmentBitmap APPsub-TLV is originated by the DRB on a 
link, it appoints the TRILL switch whose nickname appears in the 
Appointee Nickname field for the VLAN IDs corresponding to 1 bits in 
the Bit Map and revokes any Hello appointment of that TRILL switch 
for VLANs corresponding to 0 bits in the Bit Map. 


3. AppointmentList APPsub-TLV 


The AppointmentList APPsub-TLV provides a convenient method for a 
TRILL switch to indicate which TRILL switches it appoints as 
forwarders for which VLAN IDs. Such an appointment is only effective 
when the appointing TRILL switch is the DRB. 
TA ae 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Appointee Nickname | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| RESV | VLAN ID 1 | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| RESV | VLAN ID 2 | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| RESV | VLAN ID | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


~ + 


o Type: APPsub-TLV type, set to AppointmentList sub-TLV 18. 


o Length: 2 + 2 * k. If Length is not an even number, the 
APPsub-TLV is corrupt and MUST be ignored. 


O Appointee Nickname: The nickname of the TRILL switch being 
appointed as forwarder. 
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o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 


o VLAN ID: A 12-bit VLAN ID for which the appointee is being 
appointed as the forwarder. 


Type and Length are 2 bytes, because these are extended FS-LSPs. 
This APPsub-TLV, when originated by the DRB, appoints the TRILL 
switch with Appointee Nickname to be the Appointed Forwarder for the 
VLAN IDs listed. 

10.4. FGL-VLAN-Bitmap APPsub-TLV 
The FGL-VLAN-Bitmap APPsub-TLV provides a method for a TRILL switch 
to indicate mappings of FGLs to VLAN IDs that it is configured to 
perform when egressing and ingressing native frames. 


The coding is efficient when both of the following apply: 


- the VLAN IDs are compact (that is, they do not span a large 
numeric range), and 


- the FGLs and VLAN IDs are paired in a monotonically increasing 
fashion. 
1d A Ae a 
01234567890123 45 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| RESV | Starting VLAN ID | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Starting FGL | (3 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Bit Map ... (variable) 


+—+-+-4+-+-+-4+-+-... 
o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV 19. 


o Length: 5 + size of bit map in bytes. If Length is less than 5, 
the APPsub-TLV is corrupt and MUST be ignored. 


o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 
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o Starting VLAN ID: Initial VLAN ID for the mapping information as 
discussed below. 


o Starting FGL: Fine-Grained Label [RFC7172]. 


o Bit Map: Map of bits for VLAN-ID-to-FGL mappings. The size of the 
bit map is Length minus 5. If the size of the bit map is zero, 
no mappings are indicated. 


Each bit in the Bit Map corresponds to a VLAN ID and to an FGL. 

Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field 
and the Fine-Grained Label that appears in the FGL field. Bit 1 is 
for that VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and 
FGLs as unsigned integers) and so on, with Bit N generally being 
Starting VLAN ID plus N and FGL plus N. 


If a Bit Map bit is a 1, it indicates that the advertising TRILL 
switch will map between the corresponding VLAN ID and FGL on 
ingressing native frames and egressing TRILL Data packets if it is 
Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does 
not indicate any configured mapping of the VLAN ID to the FGL. 
However, VLAN ID 0x000 and VLAN ID OxFFF or any larger ID are 
invalid, and FGLs larger than OxFFFFFF are invalid; any Bit Map bits 
that correspond to an illegal VLAN ID or an illegal FGL are ignored. 


5. FGL-VLAN-Pairs APPsub-TLV 
The FGL-VLAN-Pairs APPsub-TLV provides a method for a TRILL switch to 
indicate a list of the mappings of FGLs to VLAN IDs that it is 


configured to perform when egressing and ingressing native frames. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | (2 bytes) 
4+-+-4-4+-4-4+-4-4+-4-4+-4-4+-4-4+-4-4-+ 

| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 

| Mapping RECORD 1 | (5 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...—-+-+-+ 

| Mapping RECORD 2 | (5 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 

A E EEE Ce A 

| Mapping RECORD k | (5 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+ 
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Where a Mapping RECORD has the following structure: 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| RESV | VLAN ID (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| FGL | (3 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV 20. 


o Length: 5 * k. If Length is not a multiple of 5, the APPsub-TLV 
is corrupt and MUST be ignored. 


o RESV: 4 bits that MUST be sent as zero and ignored on receipt. 
o VLAN ID: 12-bit VLAN label. 
o FGL: Fine-Grained Label [RFC7172]. 


Each Mapping RECORD indicates that the originating TRILL switch is 
configured to map between the FGL and VLAN given on egressing and 
ingressing native frames. However, VLAN ID 0x000 and VLAN ID OxFFF 
are invalid; any Mapping RECORD that corresponds to an illegal 

VLAN ID is ignored. 


11. Management Considerations 


This document primarily adds optional enhancements or optimizations. 
The only configuration parameters specified in this document are the 
number and frequency of copies of Port-Shutdown messages sent, as 
specified in Section 6.6. 


TRILL switch support of SNMPv3 is provided in the TRILL base protocol 
document [RFC6325]. MIBs have been specified in [RFC6850] and 
[RFC7784], but they do not include the configurable parameters 
specified herein. It is anticipated that YANG modules will be 
specified for TRILL. 
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Appendix A. VLAN Inhibition Example 


The per-VLAN inhibition timers (or the equivalent) are needed to be 
loop safe in the case of misconfigured bridges on a link. 


For a simple example, assume that RB1 and RB2 are the only RBridges 
on the link, that RB1 is higher priority to be the DRB, and that they 
both want VLAN 1 (the default) to be the Designated VLAN. However, 
there is a bridge between them configured so that RB1 can see all the 
frames sent by RB2 but none of the frames from RB1 can get through 

to RB2. 


Both will think they are the DRB: RB1 because it is higher priority 
even though it sees the Hellos from RB2, and RB2 because it doesn’t 
see the Hellos from RB1 and therefore thinks it is highest priority. 


Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while 
RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There 
is no problem with VLANs 2 and 4, but if you do not do something 
about it, you could have a loop involving VLAN 3. RB1 will see the 
Hellos that RB2 issues on VLAN 3 declaring itself Appointed 
Forwarder, so RB1 will be inhibited on VLAN 3. RB2 does not see the 
Hellos issued by RB1 on VLAN 3, so RB2 will become uninhibited and 
will handle VLAN 3 native traffic. 


However, this situation may change. RB2 might crash, the bridge 
might crash, RB2 might be reconfigured so it no longer tried to act 
as Appointed Forwarder for VLAN 3, or other issues may occur. So, 
RB1 has to maintain a VLAN 3 inhibition timer, and if it sees 

no Hellos from any other RBridge on the link claiming to be Appointed 
Forwarder for VLAN 3 for a long enough time, then RB1 becomes 
uninhibited for that VLAN on the port in question and can handle 
end-station traffic in VLAN 3. 
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Appendix B. Multi-Link VLAN Mapping Loop Example 


Assume that RBridges RB1 and RB2 have ports Pl and P2, respectively, 
that are both on Link L1 and that RBridges RB3 and RB4 have ports P3 
and P4, respectively, that are both on Link L2. Assume further that 
P1 and P3 are Appointed Forwarders for VLAN-x and P2 and P4 are 
Appointed Forwarders for VLAN-y. This situation is shown in the 
figure below. 


TRILL network 


| | 
hook  +---+ hook  +---+ 

| | 

+ + 


-|RB1|- -|RB2|- - - - - - - |RB3|- -|RB4|- 
+--+ +---+ +---+ +---+ 
P1| P2 | P3 | P4| 
| | | | 
| x ly | x ly 
| +e | ie ee 
L1 ---+---|mM|---+--+--- L2 ---+---|m]|---+--- 
++ | ++ 
+---+ 
|ES1| 
+---+ 


Further assume that L1 and L2 are each bridged LANs that include a 
device M, presumably a bridge, that maps VLAN-x into VLAN-y and 
VLAN-y into VLAN-x. 


If end station ES1 originated a broadcast or other multi-destination 


frame in VLAN-y, it would be ingressed by RB2. (The frame would also 
be mapped to VLAN-x and ingressed by RB1, but we initially ignore 
that.) RB2 will flood the resulting TRILL Data packet through the 


campus, and, at least in the broadcast and unknown unicast cases, 

it will get to RB4, where it will be egressed to L2. Inside L2, this 
broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3 
then floods the resulting TRILL Data packet through the campus, this 
time with an Inner.VLAN of VLAN-x, as a result of which it will be 
egressed by RB1 into L1. Inside Ll, it will be mapped back to VLAN-y 
and then ingressed by RB2, completing the loop. The packet will loop 
indefinitely, because in native form on L1 and L2 it has no TRILL 

Hop Count, and an indefinitely large number of copies will be 
delivered to ES1 and any other end station so situated. The same 
problem would occur even if P1 and P2 were on the same RBridge and/or 
P3 and P4 were on the same RBridge. Actually, because the original 
frame was also mapped to VLAN-x inside L1 and ingressed by RB1, there 
are two copies looping around in opposite directions. 
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The use of Fine-Grained Labels [RFC7172] complicates but does not 
essentially change the potential problem. 


This example shows why VLAN mapping between Appointed Forwarder ports 
on a TRILL link is loop unsafe. When such a situation is detected, 
the DRB on the link changes Appointed Forwarders as necessary to 
assure that a single RBridge port is Appointed Forwarder for all 
VLANs involved in mapping. This change makes the situation 

loop safe. 


Appendix C. Changes to RFCs 6325, 6439, and 7177 


This document updates [RFC6325], obsoletes [RFC6439], and updates 
[RFC7177]. 


The change to [RFC6325], the TRILL base protocol, is as follows: 
Addition of mandatory support for E-L1CS FS-LSPs. 
Changes to [RFC6439], which this document obsoletes, are as follows: 


1. Specification of APPsub-TLVs and procedures to be used in 
E-L1CS FS-LSP forwarder appointments. 


2. Incorporation of updates to [RFC6439] that appeared in Section 10 
of RFC 7180, which has been obsoleted by [RFC7780]. They appear 
primarily in Section 4 of this document. 


3. Addition of an optional FGL-VLAN consistency check feature, 
including specification of APPsub-TLVs. 


4. Deletion of references to the October 2011 version of the document 
"RBridges: Campus VLAN and Priority Regions" 
(draft-ietf-trill-rbridge-vlan-mapping), which has been dropped by 
the TRILL WG. 


5. Addition of the Port-Shutdown message. 

6. Elimination of the requirement that the DRB not send appointments 
in Hellos until its DRB inhibition timer has expired. This was an 
unnecessary safety precaution that is pointless, given that 


appointments in E-L1CS FS-LSPs are immediately visible. 


7. Addition of three optional methods (Section 3.2) to optimize 
(reduce) inhibition time under various circumstances. 


8. Editorial changes. 


Eastlake, et al. Standards Track [Page 39] 


RFC 8139 TRILL: Appointed Forwarders June 2017 


Changes to [RFC7177] are as follows: 


As provided in Section 6, TRILL switches SHOULD treat the 

reception of a Port-Shutdown RBridge Channel message from RB1 
listing port Pl as if it were an event A3 as specified in 
[RFC7177], 


resulting in transition of any adjacency to P1 to the 
Detect state. 
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